Using the feature exchange language in the Next Generation Controller

The Air Force has two ongoing initiatives to aid the ailing U.S. Machine Tool Industry. The first is the Intelligent Machining Workstation (IMW), which has the goal of automatically producing one-off quality parts. The second is a Next Generation Controller (NGC) initiative, which has as its primary objective to design and specify an open architecture controller for machine tools. This report analyzes whether the integration language developed for the IMW is adequate to support the requirements of an integration language needed to build the NGC. The IMW's Feature Exchange Language (FEL) is a simple message oriented language designed to integrate diverse modules. The NGC has a specified need to design a Neutral Manufacturing Language, which can be readily used to integrate diverse third-party modules into a coherent controller. We show how with a few minor extensions FEL can be used to meet this need. 1. Executive Summary The Feature Exchange Language (FEL) is a simple language that was designed for communicating modules. It was initially developed at Carnegie Mellon as part of the Air Force's Intelligent Machining Workstation (IMW) program. In this context, FEL was used to represent part geometry and communicate between IMW modules: a planner, a modeler, a cutting expert, a holding expert and a low level controller. The Next Generation Controller (NGC) has some modules in common with IMW, but it also emphasizes lower level processing and timing constraints, namely, the system must be fast enough and it must act on time. In addition, the NGC must be designed so that third party vendors can readily include their modules (e.g., a new collision avoidance package or a new board for 3-axis motion control). As part of the NGC architecture, a Neutral Manufacturing Language (NML) is presumed to tie together the various NGC modules. However, this language has also been envisioned as a means of programming the NGC, which could mean many things depending on the components of a particular controller. For example, a particular NGC controller could have a 3-axis motion controller, a set of special purpose vision boards and a higher level part programming environment. All of these components must be programmed in our new language. The question answered by this report is: "Does FEL suffice and, if not, how would it have to be extended to satisfy the requirements of NML?" This report gives several different detailed examples of how FEL could be used to program different representative NGC modules and their connections. For example: (1) Programmable Modules or Boards Some modules and board are programmable in the sense that they can interpret their own language complete with control structures and other programming devices. In this case, the program or parameters to a program must be represented in NML. (2) Module Configuration or Board Configuration Some modules (or boards) are mostly hardcoded for a particular task, but it is possible to set key registers and control the path of data and a few internal functions. In this case, the names of the registers and their values must be represented in NML. (3) Part Descriptions dike PDES) ~ The NGC is going to include a planning module and it will almost certainly be feature oriented. In this case, the features of the part and their parameters must be represented in NML. (4) Process Oriented Part Descriptions flike NC data) A design feature of a part does not necessarily match a process features (Lev how that feature is made). In this case, the process data must be represented in NML. (5) Connecting Modules There are many possible modules that can make up an NGC and they must all communicate in NML. These examples describe what NML must represent. And yet there are other key constraints on NML, which will shape the language and its implementation. Perhaps, the most important additional constraint is performance. In this case, it should be possible to pass messages between modules very quickly, for example, it would be possible to have a binary representation of FEL messages and that the only data that is actually sent is a pointer to the message. The purpose of this extra level of representation would be to eliminate overhead between modules so that third party vendors could design cooperating modules even for time critical tasks (e.g., a collision avoidance algorithm internal to a motion controller). However, no matter, how the messages are sent they should have a uniform view to a human developer, system tester or diagnostician. Therefore, the tool used by these users of the system should be able to transparently view messages in the most readable way (e.g., a text representation or an iconic representation). Some components of the language are task independent and some are task dependent. The task independent elements should become a standard part of the language, while the dependent parts should be possible to change or update according to the particular NGC being configured and what modules make it up. Some examples of task independent features of the language include: (1) Transport information The name of the sender and the receiver of a message is necessary to deliver a message. (2) Time information Because most of the information in an NGC is time critical, we are choosing to make time constraints a standard component of a message. (3) Protocol information There are various protocols between modules and the message should reflect the state of a particular transaction (e.g., if the protocol is simply SEND and RECEIVED then a message should be marked as one or the other). We believe that a simple language like FEL will make a good initial model for NML, because it is simple enough to convey to third party developers and it makes it feasible for programs to automatically generate and understand messages. However, it does place some constraints on the NGC architecture, namely, most of the control structure of an NGC must be internal to the modules rather than between modules. 2. Introduction This document is a detailed, comparative evaluation of the Feature Exchange Language (FED and the Neutral Manufacturing Language (NML), aimed at determining the extent to which FEL already achieves the goals of NML. 2.1. Languages and Computational Models The first question that must always be asked when designing a new language is: why? There are two simple reasons for having a language in the first place and possibly designing a new one: (1) Standard Communications • The reason to be for a language is simply a convention for communicating ideas between people, people and machines and just machines. Clearly, every participant in a communication must be able to "speak the language' in order for it to be considered successful. The problem is that in manufacturing virtually every system is programmed differently and wants to communicate in a different way. It is no wonder that true Computer Integrated Manufacturing has proved to be so difficult (2) A Good and Simple Way to Think Besides multi-party communications, a language also gives people and machines a way to "think." For example, there are some simple analysis problems that are virtually impossible without calculus, but with it are incredibly simple. Yes, calculus is a language, it provides new words (and therefore new concepts) and legal ways of manipulating and combining those concepts. When computers are involved, we call this a computational model. The objectives of the NGC project have strong requirements for a standard way of communicating between many different types of computer modules, as well as providing a good and simple way to describe the solutions to all sorts of control problems. 2JL A Brief History of Manufacturing Control Languages This section gives a brief and incomplete history of programming languages used for manufacturing to try and pinpoint what has been the result of past attempts to introduce something new. An early Air Force program in the 195(fs also had an objective of standardizing the way we control machines. The result was Numerical Control data or NC programming, which frankly was almost too successful. It was such a radical improvement over past ways of controlling machines, that it has lasted until now and is still going strong. However, the world has not stood still during this time and our ideas and understanding of computer science and computer languages have gone through major changes, possibly 5 times. With each one of these changes, there was an attempt to keep up In manufacturing circles; however, It was only the Fortune 100 companies that could really manage these changes. As Fortran became the dominant scientific programming language for computers in the 1960's, APT (A Programming Tool) was developed to try and keep pace by providing Fortran-like representations of numeric formulas. The problem with APT was that it required the use of the "large business machine'' in order to convert it into NC data. Small companies didn't have this machine at all, and big companies had feuds over who could use the "business machine" and who had priority. In the late 1960's and 1970's, computer science began to advance quickly as the "structure of programs'' was better understood. As a result, "structured programming" became popular with languages like Algol and Pascal (and many others) gave programmers simple tools to organize and manage the control structures in their programs. These languages evolved their way into still other languages such as C and ADA, which address the need to have low level access to a machine and to manage multi-million line projects, respectively. To some degree, manufacturing skipped structured languages altogether, although there were a few important forays into very high level languages by powerful research groups (such as IBM's AUTOPASS, but this was a project before its time). About 10 years later, small companies that made robots and vision machines, began to develop structured languages (e.g., Unimate's VAL and Autornatix's RAIL). Finally in the 1980's, structured languages caught hold in the biggest manufacturing companies (e.g., GM's Karel and IBM's AML) and they also appeared in more of the new products (e.g., Adept's V+). In the late 1980's and now the 90% everyone is discussing object oriented programming based on Smalltalk, C++ and other languages that have been developed in computer science. Also Symbolic languages based on LISP, PROLOG and various Expert System shells have been used to some degree. However, not much of this has made its way into broadly accepted practice. From these experiences, we can see an unusual trend. Programmers complain, but in a few years they move on to the new methodsHowever, in manufacturing there is a sense in which only 10% of the community moves on to the next computational paradigm. The result is that NC programming is still dominant, and the chief contender is still ladder logic that predates NC programming. 2S. Other Areas Manufacturing has Used Languages The previous section concentrated on languages that control machines. This section wiH just Est a few other areas that have been accepted and used by the manufacturing community: (1) Business The business groups in manufacturing have essentially kept pace with IBM, they have used COBOL, PL/1 and RPG to do their work without too much regard to anyone else. Finally in the 1980% this has changed somewhat as more and more businesses rely on personal computers and electronic spreadsheets, and specialized accounting packages(2) Design Designers in manufacturing companies have also gone off on their own and developed various methods of describing geometry and other critical product data. As a result standards, such as IGES and tolerance standards have emerged and they are now quickly evolving to more symbolic, or feature-based, representations of products (e.g., PDES). (3) Machine to Machine Protocols During the 1970's, manufacturing companies were hopeless when it came to protocols for tying machines together. This was realized in the 198Q's; many companies participated in the development of the Manufacturing Automation Protocol (MAP), while those who could not wait started to use the computer companies' accepted products (Xerox's Ethernet, DEC's Decnet and IBM's token ring). While we have had many successful Machine Tool and AUTOFAC shows, I don't think we have any overwhelming success at this on the factory floor. (4) Research Groups There has been no lack of research interest in these areas, but the impact has been relatively modest. Carnegie Mellon's CML, MIT's LAMA, NBS's hierarchical workpackages, and IBM's many efforts have probed the limits of technology. 2.4. The FELs and NMLs Place in This History The purpose of the NGC and the trend in manufacturing is to begin the process of combining these diverse aspects of the manufacturing business and the product life cycle. For example, tool rooms, stock rooms, part programming, manufacturing engineers, machine operators, maintenance people, and system developers have historically been in different departments and used different computational tools. The NGC is starting to bring together these various concerns and therefore bringing together the tools of the past. But they don't fit together. The Feature Exchange Language faced this problem in the Air Force's Intelligent Machining Workstation program. Industry suggested using various languages for various tasks: PDES for part description, NISTs workpackages for control, NC programs for running the machine, a standard expert system shell, MAP and others (all at once, all in the same system)Each of these choices is probably fine in isolation, but when put together they represent a design and programming nightmare. For this reason, FEL was designed to be as simple as possible, while still covering all of these different areas. NML has the same problem as FEL, it too is trying to bring together many diverse areas of the manufacturing business. In many ways, it has to represent all of the areas that were covered by FEL, but in addition is has to reach down into the bowels of the control and be able to cope with the real time issues that face a controller. Therefore, this document will address these new constraints head on and consider whether or not FEL can be extended to fill the role of NML. 2.5. The Organization of This Report The sections that follow this introduction were written with the follow goals in mind: (1) to describe the current state of FEL, both to initiate readers not already familiar with FEL and to provide a basis for evaluating the extent to which FEL already meets the requirements for NML; (2) to provide a conceptual framework in which to think about the requirements of NML and to say what we believe the requirements are from the point of view provided by the fundamental questions that define this framework; (3) to show by example how FEL satisfies many of the requirements of NML; and (4) to explain some enhancements to FEL which we believe will significantly improve the language and its operational environment and will remedy some of its key deficiencies and make it a reasonable choice for NML. Section 3 (re item (1) above) desaibes the current status of FEL, including its syntax, semantics, and standard execution environment. Section 4 (re item (2) above) discusses requirements for NML in both general and specific terms. It includes a topic which we feel is especially important high-level module-to-module protocolsSections 5 through 7 aim to satisfy item (3) above. Section 5 contains a set of realistic examples of how FEL might be used to program various levels of an NGC. The examples employ control and sensing hardware with which we have first-hand experience. Section 6 discusses human interface issues. Section 7 talks about the efficiency of FEL. Section 8 (re item (4) above) describes some enhancements that we would like to make to FEL and its runtime environment, and the motivation for them. Included are: real-time support, better dialog support, simplified extensibility features, and improved error handling. Section 9 contains our general conclusions. An appendix includes the RDD items pertaining explicitly to NML and a few comments on each of them. 3. Current Status of FEL The current status of FEL, as an operational component of the our IMW prototype modules, is explained in considerable detail in our report The Operational Feature Exchange Language (see [l]). In this section we summarize, for those who have not read the previous report, the main features of the language and of the generic module application in which it is embedded. 3.1. Basic Syntax 3.1.1. The Grammar The design of FEL syntax is based on a few simple concepts: (1) sentences, (2) verbs, (3) attributes with associated values, i.e., attribute-value pairs, and (4) lists. An FEL sentence consists of a verb and one or more lists of attribute-value pairs. An FEL verb is a symbol from a table of legal verbs. An FEL attribute is a symbol from a table of legal attributes. An FEL value is an integer, a real number, a dimensioned integer, a dimensioned real number, a symbol, a string, or a list of values. We plan to extend the syntax to effectively allow a list of attribute-value pairs to be the value of an attribute. This new type would be similar to a struct in C and a record in Pascal. (Currently, if such a Ust were to appear in the value position of an attribute-value pair, it would be treated as a list of lists of uninterpreted symbols and other values. The mechanisms that find and extract the values of attributes do not work on such lists.) Here is what a partial grammar for FEL looks like: Sentence = "(" ")" I "(" ")" list of Feature list = I NIL Feature List = "<" ")" List of Pairs = "(" ' T I NIL The following is an example of a typical FEL sentence, in this case a portion of the response of the IMW Process Planner to a request to plan setups for a part to be machined: (planned ( (name (type (to (from ( (name (type (application (environment (part (stock (translation G0942) message) hi) px) ) planjboss) pianning_op) planner) im) boss) S0235) (0*G 0.5 0.25)) ( (name (type (method (inajor_ref (minor__ref (ma jor_pos (minorjpos (ma j or_no rma 1 (minor_nonnal (x__rotation (y_rotation (z_rotation ( (name (type (face (p_vector (l_vector (w_vector (d_vector ( (name (type (method (major_ ref (minor_ref (major_pos (minor__pos (ma j or^normal (minor_normal (x_rotation (y_rotation (z_rotation ( (name (type (face (R_vector (l_yector (w^vector (director setup_47) se tup) v i s e ) mx_6) mx_3) down) on_s o1id_jaw) (0.0 0.0 1 . 0 ) ) (0.0 1.0 0 .0 ) ) 0) 0) 0) ) face_48) face) mx_5) ( 3 .5 2 .5 1.5)) ( -3 .5 0.0 0 .0 ) ) ( 0 . 0 2 . 5 0 .0 ) ) ( 0.0 0.0 0 . 2 5 ) ) setup_49) se tup) v i s e ) xax_5) xnx_3) on_solid_jaw) down) (0.0 0.0 1.0)) (0.0 1.0 0 .0 ) ) -90) 0) 0) ) face_50) face) mx_l) { 3 .5 0.0 1 .5)) ( -3 .5 0.0 0 . 0 ) ) ( 0.0 0.0 1 . 5 ) ) ( 0.0 0 .5 0 . 0 ) ) )